Chipset support for managing hardware interrupts in a virtual machine system

ABSTRACT

In one embodiment, an apparatus includes a set of multiplex blocks coupled with an interrupt controller and multiple interrupt request lines, and a virtual machine monitor block (VMM) coupled to the set of multiplex blocks. Each multiplex block corresponds to a distinct interrupt request line. Each multiplex block is to route the interrupt request signal received via the corresponding interrupt request line either to the interrupt controller or the VMM block depending on a current configuration value of this multiplex block.

FIELD

Embodiments of the invention relate generally to virtual machines, andmore specifically to managing hardware interrupts in a virtual machinesystem.

BACKGROUND OF THE INVENTION

In a typical computer system, devices request services from systemsoftware by generating interrupt requests, which are propagated to aninterrupt controller via multiple interrupt request lines. Once theinterrupt controller identifies an active interrupt request line, itsends an interrupt signal to the processor. In response, the interruptcontroller interface logic on the processor determines whether thesoftware is ready to receive the interrupt. If the software is not readyto receive the interrupt, the interrupt is held in a pending state untilthe software becomes ready. Once the software is determined to be ready,the interrupt controller interface logic requests the interruptcontroller to report which of the pending interrupts is highestpriority. The interrupt controller prioritizes among the variousinterrupt request lines and identifies the highest priority interruptrequest to the processor which then transfers control flow to the codethat handles that interrupt request.

In a conventional operating system (OS), all the interrupts arecontrolled by a single entity known as an OS kernel. In a virtualmachine system, a virtual-machine monitor (VMM) should have ultimatecontrol over various operations and events occurring in the system toprovide proper operation of virtual machines and for protection from andbetween virtual machines. To achieve this, the VMM typically receivescontrol when guest software accesses certain hardware resources orcertain events occur, such as an interrupt or an exception. Inparticular, when system devices generate interrupts, the VMM mayintercede between the virtual machine and the interrupt controlleringdevice. That is, when an interrupt signal is raised, the currentlyrunning virtual machine is interrupted and control of the processor ispassed to the VMM. The VMM then receives the interrupt and handles theinterrupt or delivers the interrupt to an appropriate virtual machine.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example, and not by wayof limitation, in the figures of the accompanying drawings and in whichlike reference numerals refer to similar elements and in which:

FIG. 1 illustrates one embodiment of a virtual-machine environment, inwhich the present invention may operate;

FIG. 2 is a block diagram of one embodiment of a system for processinginterrupts in a virtual machine environment;

FIG. 3 is a flow diagram of one embodiment of a process for handlinginterrupts in a virtual machine system;

FIG. 4 is a flow diagram of one embodiment of a process for configuringthe handling of interrupts during execution of a virtual machine in avirtual machine system; and

FIG. 5 is a flow diagram of one embodiment of a process for managing theconfiguration of the chipset interrupt control during a switch invirtual machines in a virtual machine system.

DESCRIPTION OF EMBODIMENTS

A method and apparatus for controlling interrupts in a virtual machinesystem are described. In the following description, for purposes ofexplanation, numerous specific details are set forth in order to providea thorough understanding of the present invention. It will be apparent,however, to one skilled in the art that the present invention can bepracticed without these specific details.

Some portions of the detailed descriptions that follow are presented interms of algorithms and symbolic representations of operations on databits within a computer system's registers or memory. These algorithmicdescriptions and representations are the means used by those skilled inthe data processing arts to most effectively convey the substance oftheir work to others skilled in the art. An algorithm is here, andgenerally, conceived to be a self-consistent sequence of operationsleading to a desired result. The operations are those requiring physicalmanipulations of physical quantities. Usually, though not necessarily,these quantities take the form of electrical or magnetic signals capableof being stored, transferred, combined, compared, and otherwisemanipulated. It has proven convenient at times, principally for reasonsof common usage, to refer to these signals as bits, values, elements,symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities. Unlessspecifically stated otherwise as apparent from the followingdiscussions, it is appreciated that throughout the present invention,discussions utilizing terms such as “processing” or “computing” or“calculating” or “determining” or the like, may refer to the action andprocesses of a computer system, or similar electronic computing device,that manipulates and transforms data represented as physical(electronic) quantities within the computer system's registers andmemories into other data similarly represented as physical quantitieswithin the computer-system memories or registers or other suchinformation storage, transmission or display devices.

In the following detailed description of the embodiments, reference ismade to the accompanying drawings that show, by way of illustration,specific embodiments in which the invention may be practiced. In thedrawings, like numerals describe substantially similar componentsthroughout the several views. These embodiments are described insufficient detail to enable those skilled in the art to practice theinvention. Other embodiments may be utilized and structural, logical,and electrical changes may be made without departing from the scope ofthe present invention. Moreover, it is to be understood that the variousembodiments of the invention, although different, are not necessarilymutually exclusive. For example, a particular feature, structure, orcharacteristic described in one embodiment may be included within otherembodiments. The following detailed description is, therefore, not to betaken in a limiting sense, and the scope of the present invention isdefined only by the appended claims, along with the full scope ofequivalents to which such claims are entitled.

Although the below examples may describe embodiments of the presentinvention in the context of execution units and logic circuits, otherembodiments of the present invention can be accomplished by way ofsoftware. For example, in some embodiments, the present invention may beprovided as a computer program product or software which may include amachine or computer-readable medium having stored thereon instructionswhich may be used to program a computer (or other electronic devices) toperform a process according to the present invention. In otherembodiments, steps of the present invention might be performed byspecific hardware components that contain hardwired logic for performingthe steps, or by any combination of programmed computer components andcustom hardware components.

Thus, a machine-readable medium may include any mechanism for storing ortransmitting information in a form readable by a machine (e.g., acomputer), but is not limited to, floppy diskettes, optical disks,Compact Disc, Read-Only Memory (CD-ROMs), and magneto-optical disks,Read-Only Memory (ROMs), Random Access Memory (RAM), ErasableProgrammable Read-Only Memory (EPROM), Electrically ErasableProgrammable Read-Only Memory (EEPROM), magnetic or optical cards, flashmemory, a transmission over the Internet, electrical, optical,acoustical or other forms of propagated signals (e.g., carrier waves,infrared signals, digital signals, etc.) or the like.

Further, a design may go through various stages, from creation tosimulation to fabrication. Data representing a design may represent thedesign in a number of manners. First, as is useful in simulations, thehardware may be represented using a hardware description language oranother functional description language. Additionally, a circuit levelmodel with logic and/or transistor gates may be produced at some stagesof the design process. Furthermore, most designs, at some stage, reach alevel of data representing the physical placement of various devices inthe hardware model. In the case where conventional semiconductorfabrication techniques are used, data representing a hardware model maybe the data specifying the presence or absence of various features ondifferent mask layers for masks used to produce the integrated circuit.In any representation of the design, the data may be stored in any formof a machine-readable medium. An optical or electrical wave modulated orotherwise generated to transmit such information, a memory, or amagnetic or optical storage such as a disc may be the machine readablemedium. Any of these mediums may “carry” or “indicate” the design orsoftware information. When an electrical carrier wave indicating orcarrying the code or design is transmitted, to the extent that copying,buffering, or re-transmission of the electrical signal is performed, anew copy is made. Thus, a communication provider or a network providermay make copies of an article (a carrier wave) embodying techniques ofthe present invention.

FIG. 1 illustrates one embodiment of a virtual-machine environment 100,in which the present invention may operate. In this embodiment, bareplatform hardware 116 comprises a computing platform, which may becapable, for example, of executing a standard operating system (OS) or avirtual-machine monitor (VMM), such as a VMM 112.

The VMM 112, though typically implemented in software, may emulate andexport a bare machine interface to higher level software. Such higherlevel software may comprise a standard or real-time OS, may be a highlystripped down operating environment with limited operating systemfunctionality, may not include traditional OS facilities, etc.Alternatively, for example, the VMM 112 may be run within, or on top of,another VMM. VMMs may be implemented, for example, in hardware,software, firmware or by a combination of various techniques.

The platform hardware 116 can be of a personal computer (PC), mainframe,handheld device, portable computer, set-top box, or any other computingsystem. The platform hardware 116 includes a processor 118, memory 120,chipset core logic 122 and one or more interrupt sources 128.

Processor 118 can be any type of processor capable of executingsoftware, such as a microprocessor, digital signal processor,microcontroller, or the like. The processor 118 may include microcode,programmable logic or hardcoded logic for performing the execution ofmethod embodiments of the present invention. Though FIG. 1 shows onlyone such processor 118, there may be one or more processors in thesystem.

Memory 120 can be a hard disk, a floppy disk, random access memory(RAM), read only memory (ROM), flash memory, any combination of theabove devices, or any other type of machine medium readable by processor118. Memory 120 may store instructions and/or data for performing theexecution of method embodiments of the present invention.

The one or more interrupt sources 128 may be, for example, input-output(I/O) devices (e.g., network interface cards, communication ports, videocontrollers, disk controllers) on system buses (e.g., PCI, ISA, AGP) ordevices integrated into the chipset logic or processor (e.g., real-timeclocks, programmable timers, performance counters).

The VMM 112 presents to other software (i.e., “guest” software) theabstraction of one or more virtual machines (VMs), which may provide thesame or different abstractions to the various guests. FIG. 1 shows twoVMs, 102 and 114. The guest software running on each VM may include aguest OS such as a guest OS 104 or 106 and various guest softwareapplications 108 and 110. Each of the guest OSs 104 and 106 expect toaccess physical resources (e.g., processor registers, memory and I/Odevices) within the VMs 102 and 114 on which the guest OS 104 or 106 isrunning and to handle various events including interrupts generated bysystem devices during the operation of the VMs 102 and 114.

Some interrupts may need to be handled by a currently operating VM.Other interrupts may need to be handled by the VMM 112 or a VM that isnot currently operating. If the interrupt is to be handled by thecurrently-operating VM, control remains with this VM, and the interruptis delivered to this VM if it is ready to receive interrupts (asindicated, for example, by an interrupt flag in a designated processorregister). If the interrupt is to be handled by the VMM 112, control istransferred to the VMM 112. The transfer of control from guest softwareto the VMM 112 is referred to herein as a VM exit. After receivingcontrol following the VM exit, the VMM 112 may perform a variety ofprocessing, including, for example, acknowledging and handling theinterrupt, after which it may return control to guest software. If theVMM does not handle the interrupt itself, it may facilitate delivery ofthe interrupt to a VM designated to handle the interrupt. The transferof control from the VMM to guest software is referred to as a VM entry.

In one embodiment, the processor 118 controls the operation of the VMs102 and 114 in accordance with data stored in a virtual machine controlstructure (VMCS) 124. The VMCS 124 is a structure that may contain stateof guest software, state of the VMM 112, execution control informationindicating how the VMM 112 wishes to limit or otherwise controloperation of guest software, information controlling transitions betweenthe VMM 112 and a VM, etc. In one embodiment, the VMCS 124 is stored inmemory 120. In another embodiment, the VMCS 124 is stored in theprocessor 118. In some embodiments, multiple VMCS structures are used tosupport multiple VMs.

The processor 118 reads information from the VMCS 124 to determine theexecution environment of the VM and to constrain its behavior. Forexample, the processor 118 may consult the execution control informationin the VMCS to determine if external interrupts are to cause VM exits.When a VM exit occurs, components of the processor state used by guestsoftware are saved to the VMCS 124, and components of the processorstate required by the VMM 112 are loaded from the VMCS 124. When a VMentry occurs, the processor state that was saved at the VM exit isrestored using data stored in the VMCS 124, and control is returned toguest software.

In one embodiment, chipset core logic 122 is coupled to the processor118 to assist the processor 118 in handling interrupts generated by theinterrupt sources 128, described below. The chipset logic 122 may bepart of the processor 118 or an independent component. The chipset logic122 may include microcode, programmable logic or hardcoded logic forperforming the execution of method embodiments of the present invention.Though FIG. 1 shows only one chipset logic 122, the system may containone or more such chipsets.

As will be discussed in more detail below, the chipset core logic 122controls the distribution of interrupts generated by the one or moreinterrupt sources 128. If an interrupt is generated by a device that ismanaged by a currently operating VM, the chipset core logic 122 sendsthe interrupt request to the processor 118 for delivery to the currentlyoperating VM. If an interrupt is generated by a device that is notmanaged by a currently operating VM, the chipset core logic 122 eitherholds the interrupt pending or indicates to the processor 118 thatcontrol is to be transitioned to the VMM 112.

FIG. 2 is a block diagram of one embodiment of a system 200 forprocessing interrupts in a virtual machine environment. The system 200includes a processor 220 and chipset core logic 202. The system 200 isactive during operation of the VMM and during operation of guestsoftware. The term “currently operating software” is used herein torefer to the VMM or the currently operating guest software (i.e., thecurrently operating VM).

In one embodiment, the chipset core logic 202 includes an interruptcontroller 204, a set of multiplex blocks 206, and a VMM block 210.

The interrupt controller 204 receives interrupt request signalsgenerated by system devices and delivers interrupt requests (INTRs) tothe processor 220. In an embodiment, the processor acknowledges aninterrupt request from the interrupt controller 204 by an interruptacknowledgement bus cycle (INTA), for which the interrupt controller 204returns the vector number of the interrupt service routine to beexecuted to service the interrupt.

The interrupt controller 204 has a state machine and a number ofregisters, which may include readable and writable registers, read-onlyregisters and write-only registers. In one embodiment, the interruptcontroller 204 includes a read and write access path to its registers toallow a VMM to save the current state of the interrupt controller 204(e.g., in the VMCS or in a VMM data structure) and to restore theinterrupt controller state associated with a VM that is to be invoked.In addition, in one embodiment, the current state of the state machinein the interrupt controller 204 is readable and writable to allow theVMM to switch VMs. In another embodiment, the state machine in theinterrupt controller 204 is readable and the VMM has to replay a seriesof writes to the interrupt controller 204 to place the interruptcontroller 204 into the correct state.

The interrupt controller 204 may be a conventional interrupt controller(e.g., an 8259A interrupt controller) that is enhanced to provide a readand write access path to its registers and state machine. The read andwrite access path may be implemented, for example, as an extension tochipset specific registers to provide the behavior that is identical tothe behavior of the conventional interrupt controller (e.g., theread-only registers remain read-only unless being accessed by the VMM).This can be achieved, for example, by providing access to the registersof the interrupt controller through memory mapped I/O registers. Theinterrupt controller 204 may include masking and prioritization logicthat is known to one of ordinary skill in the art.

The interrupt controller 204 is coupled to the multiplex blocks 206. Thenumber of multiplex blocks 206 is equal to the number of interruptrequest lines 208. Each interrupt request line 208 propagates interruptrequests generated by a specific device to a corresponding multiplexblock 206.

In a virtual machine system, a device may be managed by a certain VM andgenerate interrupts that need to be delivered to this VM. For example, avideo capture card may be managed directly by a single VM and may not bevisible to other VMs. Alternatively, a device may be managed by severalVMs and generate interrupts that need to be delivered to multiple VMs.Yet, alternatively, the device may be managed by the VMM and generateinterrupts that need to be delivered to the VMM. For example, anintegrated drive electronics (IDE) controller may be managed exclusivelyby the VMM.

Each multiplex block 206 receives interrupt request signals generated bya specific device. Depending on its setting, each multiplex block 206may route an interrupt request signal to the interrupt controller 204 orthe VMM block 210. In one embodiment, the multiplex blocks 206 are setby the VMM. The VMM may set the multiplex blocks 206 prior to requestinga VM entry and/or following a VM exit. In another embodiment, themultiplex blocks 206 are set by the processor as part of a VM entryand/or a VM exit. The values used to set the multiplex blocks 206 may bestored in the VMCS or in any other data structure.

In one embodiment illustrated in FIG. 2, when a multiplex block 206 isset to route interrupt request signals generated by a correspondingdevice to the interrupt controller 204, the interrupt request signal maybe routed to a specific input of the interrupt controller 204. Forexample, FIG. 2 shows interrupt IRQ0 being routed to input 1 of theinterrupt controller 204 and IRQ1 is shown routed to input 0 of theinterrupt controller 204. Other embodiments allow the interrupt requestsignal to be routed to a single fixed input of the interrupt controller204.

In addition, in the embodiment illustrated in FIG. 2, when a multiplexblock 206 is set to route interrupt request signals generated by acorresponding device to the VMM block 210, the interrupt request signalcan be routed to a fixed input of the VMM block 210. For example, in theexample shown in FIG. 2, IRQn is routed to the n^(th) input of the VMMblock 210. In another embodiment, the interrupt request signal may berouted by the multiplex block 206 to an arbitrary input of the VMM block210.

The VMM block 210 includes a number of input lines connected to theoutput lines of the multiplex blocks 206. The VMM block 210 generates anoutput signal indicating to the processor 200 that control needs to betransitioned to the VMM. In one embodiment, the output signal isgenerated by combining the interrupt request signals routed to the VMMblock 210 with an external signal generated by an external signal source218. An external signal may be any signal, other than a signal of anexternal interrupt type, that may be configured by the VMM to cause a VMexist. For example, as shown in FIG. 2, an external signal may be anon-maskable interrupt (NMI) signal that is configured to cause a VMexit each time the NMI occurs. The interrupt request signals arecombined with the external signal using a Boolean OR operatorillustrated by a gate 216.

In one embodiment, the VMM block 210 includes a mask register 212 thatcan mask an interrupt request signal routed to the VMM block 210. In oneembodiment, the VMM configures the mask register 212 to allow masking ofinterrupt request signals generated by certain devices. Masking may beused when the VMM does not need to be notified about interruptsgenerated by a device managed exclusively by a non-currently operatingVM. In one embodiment, the mask register 212 is set by the VMM. The VMMmay set the mask register 212 prior to requesting a VM entry and/orfollowing a VM exit. In another embodiment, the mask register 212 is setby the processor as part of a VM entry and/or a VM exit. The value usedto set the mask register 212 may be stored in the VMCS or in any otherdata structure.

In one embodiment, the VMM block 210 includes a status register 214 thatstores status of interrupt input lines of the VMM block 210. In oneembodiment, when an interrupt request signal is asserted on an interruptinput line of the VMM block 210, a bit associated with this interruptinput line in the status register 214 is set. The status register 214may be read by the VMM to obtain the status of the interrupt input linesof the VMM block 210. The status may be used, for example, to determinewhether the output signal sent to the processor 220 by the VMM block 210resulted from an interrupt propagated from an interrupt request line 208or from an external signal (e.g., an NMI signal) generated by theexternal signal source 218.

As discussed above, in one embodiment, the VMM configures the multiplexblocks 206 prior to requesting a transfer of control to a VM. In thisembodiment, once the control is transferred to a VM as requested by theVMM, only interrupt request signals generated by devices managed by theVM are allowed to reach the interrupt controller 204. Interrupts managedby the VMM are routed to the VMM block 210. Interrupts managed by otherVMs are routed to the VMM block and may be masked using masking register212. Thus, the chipset core logic 202 allows a currently-operating VM tocontrol all the interrupts generated by the devices managed by thecurrently-operating VM, while allowing the VMM to gain control overinterrupts generated by devices owned by the VMM and other VMs.

In some embodiments, the chipset core logic 202 may include multipleinterrupt controllers 204, with each interrupt controller 204 serving acorresponding VM. In those embodiments, the VMM does not need to saveand restore the state of the interrupt controller each time it switchesfrom one VM to another.

As discussed above, in some embodiments, the multiplex blocks 206 andmask register 212 are configured as part of a VM entry (e.g., by the VMMbefore requesting a VM entry or by the processor when performing a VMentry). Hence, the settings of the multiplex blocks 206 and maskregister 212 remain unchanged following a VM exit, and interruptsgenerated during the operation of the VMM are routed according to thesettings of a previously-operating VM. That is, if interrupts are notmasked by the VMM, they may be delivered to the VMM via the interruptcontroller 204 or the VMM block 210 using the mechanisms discussedabove. The designated software within the VMM then handles theseinterrupts appropriately.

In other embodiments, the multiplex blocks 206 and mask register 212 areconfigured as part of a VM exit (e.g., by the VMM following a VM exit orby the processor when performing a VM exit). Hence, the multiplex blocks206 and mask register 212 may be changed to route interrupts generatedduring the operation of the VMM differently than during operation of theVM which was running previously.

FIG. 3 is a flow diagram of one embodiment of a process 300 for handlinginterrupts in a virtual machine system. The process may be performed byprocessing logic that may comprise hardware (e.g., circuitry, dedicatedlogic, programmable logic, microcode, etc.), software (such as run on ageneral purpose computer system or a dedicated machine), or acombination of both. In one embodiment, processing logic is implementedin chipset core logic 202 of FIG. 2.

Referring to FIG. 3, process 300 begins with processing logic receiving,at a multiplex block, an interrupt request signal generated by a device(processing block 302). As discussed above, each multiplex block iscoupled with a distinct interrupt request line that delivers interruptrequest signals generated by a certain device.

At decision box 304, processing logic determines whether the interruptrequest signal is to be routed to the interrupt controller. In oneembodiment, this determination is done based on the configurationperformed by the VMM.

If the determination made at decision box 304 is positive, processinglogic sends the interrupt request signal to the interrupt controller(processing block 306), which may, according to the architecture of theinterrupt controller, send the interrupt request to the processor(processing block 308). The interrupt controller may perform masking andprioritization of interrupts.

If the determination made at decision box 304 is negative, processinglogic routes the interrupt request signal to the VMM block (processingblock 310) and updates a status register of the VMM block to indicatethat a signal has been asserted on an interrupt input line of the VMMblock (processing block 312). Next, processing logic determines whetherthe interrupt request signal routed to the VMM block is masked (decisionbox 314). In one embodiment, the determination is made based on data setby the VMM in a mask register of the VMM block. If the interrupt requestsignal is masked, processing logic holds the interrupt pending(processing block 316). The interrupt may be held pending, for example,until a VM managing the device that generated this interrupt is invoked.At the time the VM managing the device is invoked, the VMM will modifythe configuration of the multiplex blocks to route the interrupt requestto the interrupt controller and hence allow the VM to manage the devicedirectly.

If the interrupt request signal is not masked, processing logicgenerates an internal signal (processing block 318), combines theinternal signal with an external signal generated by a designatedexternal signal source (e.g., an NMI source) using the OR operator(processing block 320), and delivers the resulting output signal to theprocessor (processing block 322).

The output signal may cause the processor to transfer control to theVMM. The VMM may then read the status register of the VMM block,determine that the signal resulted from an external interrupt, andhandle this external interrupt itself or invoke an appropriate VM tohandle it. It should be noted that an external signal (e.g., NMI)causing the output signal may require some predefined operations to beperformed by the processor when asserted. If these predefined operationsare different from the desired behavior, then the processor blocks theoutput signal to avoid the occurrence of the predefined operations. Forexample, an NMI may cause a transition within the VMM (e.g., byvectoring the NMI) when it is asserted during operation of the VMM.Blocking the NMI signal following the VM exit caused by the assertion ofthe NMI prevents the occurrence of the predefined transition within theVMM.

FIG. 4 is a flow diagram of one embodiment of a process 400 for handlinginterrupts in a virtual machine system. The process may be performed byprocessing logic that may comprise hardware (e.g., circuitry, dedicatedlogic, programmable logic, microcode, etc.), software (such as run on ageneral purpose computer system or a dedicated machine), or acombination of both. In one embodiment, processing logic is implementedin a VMM such as the VMM 112 of FIG. 1.

Referring to FIG. 4, process 400 begins with processing logicidentifying interrupt request lines that are coupled to devices managedby a VM to be invoked (processing block 401). In one embodiment, theseinterrupt request lines are identified using data stored in the VMCS orany other data structure.

Next, processing logic configures a set of multiplex blocks (processingblock 402). Based on this configuration, only interrupt request signalsfrom the devices managed by the VM to be invoked can reach the interruptcontroller. All the remaining interrupt signals are to be routed to theVMM block. In addition, in another embodiment, the VMM may configure themultiplex blocks to route the interrupt to a particular input of the VMMblock.

At processing block 404, processing logic configures a mask register inthe VMM block to allow selective masking of interrupt request signalsrouted to the VMM block. The selective masking can be used, for example,to hold some interrupt requests pending. Interrupt requests may be heldpending if, for example, the VMM does not need to be notified aboutthese interrupt requests because they come from a device that is managedexclusively by another VM. However, some interrupts belonging to anotherVM may not be masked if, for example, the other VM needs to run at ahigher priority than the currently running VM. An example of such asituation is a VM which maintains some real-time quality of service withrespect to some device (e.g., all interrupts need to be serviced in aspecific amount of time).

At processing block 408, processing logic sets designated executioncontrol fields in the VMCS to allow the VM being invoked to control I/Oaccesses to the interrupt controller and delivery of hardwareinterrupts. For example, the VMM may set designated execution controlfields in the VMCS such that accesses to the I/O ports of the interruptcontroller do not cause VM exits.

At processing block 410, processing logic sets a designated executioncontrol field in the VMCS to cause a VM exit on each event generatedwhen the VMM block asserts its output signal to the CPU. In oneembodiment, the event may be a non-maskable interrupt (NMI). Otherembodiments may use other events, according to the architecture of thechipset core logic and system. The VMM may also need to set controlssuch that certain predefined operations following VM exits are preventedfrom happening. For example, if the output signal of the VMM block ofFIG. 2 is coupled to the NMI input of the processor, then the NMI signalmay need to be blocked following VM exits that result from the assertionof the NMI signal.

At processing block 412, processing logic executes a VM entryinstruction to request a transfer of control to the VM. Any mechanism inthe art may be used to facilitate this transfer of control to the VM.After the transfer of control to the VM, the VM can directly access theinterrupt controller (e.g., using I/O operations) and interrupts routedthrough the interrupt controller will be handled directly by the VM,with no intervention by the VMM.

FIG. 5 is a flow diagram of one embodiment of a process 500 for managingchipset core logic state during a switch from one VM to another VM. Theprocess may be performed by processing logic that may comprise hardware(e.g., circuitry, dedicated logic, programmable logic, microcode, etc.),software (such as run on a general purpose computer system or adedicated machine), or a combination of both. In one embodiment,processing logic is implemented in a VMM such as the VMM 112 of FIG. 1.

Referring to FIG. 5, process 500 begins with processing logicrecognizing that a transfer of control from one VM to another VM ispending (processing block 510). This may occur, for example, if the VMMis managing more than one VM, providing time slices to each VM in turn,similarly to how a traditional operating system may time slice processeson a single CPU.

At processing block 520, processing logic saves the current state of theinterrupt controller. The state may be saved in the VMCS or any otherdesignated data structure. In an embodiment, this saving of state isperformed by the VMM. In another embodiment, the saving of the interruptcontroller state is performed by the processor. In one embodiment, thesavings of the interrupt controller state is performed as part of theprocessing at the time of a VM exit. Additionally, processing logic mayneed to save the state of the multiplex controls, and the VMM blockmasking register. The saving of state relies on having the ability toread all appropriate state in the chipset core logic, as describedabove.

At processing block 540, processing logic restores the chipset corelogic state from the previous operation of the VM to be activated. Thisrestoration includes writing all appropriate state to the interruptcontroller to configure the masking and control registers and statemachine configuration that was present when the VM to be activated waslast active. Additionally, the multiplex blocks and VMM block controls(e.g., masking register) in the chipset core logic may need to bereconfigured for the new VM, as described above. This restoration ofstate relies on having the ability to write to all appropriate state inthe chipset core logic. In one embodiment, this restoration of chipsetcore logic state is performed by the VMM. In another embodiment, it isperformed by the processor as part of the VM entry to the new VM.

At processing block 560, the VMM requests a transfer of control to theVM. In one embodiment, the VMM executes an instruction to initiate thetransfer. Any mechanism in the art may be used to facilitate thistransfer of control to the VM.

It should be noted that process 500 assumes that the execution controlswere set appropriately prior to the first entry to the new VM (asdescribed with regard to process 400).

Thus, a method and apparatus for handling interrupts in a virtualmachine system have been described. It is to be understood that theabove description is intended to be illustrative, and not restrictive.Many other embodiments will be apparent to those of skill in the artupon reading and understanding the above description. The scope of theinvention should, therefore, be determined with reference to theappended claims, along with the full scope of equivalents to which suchclaims are entitled.

1.-12. (canceled)
 13. A method comprising: receiving, at a multiplexblock, an interrupt request signal from a device via an interruptrequest line coupled with the multiplex block; and determining, based ona current configuration value of the multiplex block, whether theinterrupt request signal is to be sent to an interrupt controller or avirtual machine monitor (VMM) block coupled to the multiplex block. 14.The method of claim 13 wherein: the current configuration value of themultiplex block requires that the interrupt request signal be sent tothe interrupt controller if the device is managed by acurrently-operating virtual machine (VM); and the current configurationvalue of the multiplex block requires that the interrupt request signalbe sent to the VMM block if the device is not managed by thecurrently-operating VM.
 15. The method of claim 13 further comprisingdetermining whether the interrupt request signal sent to the VMM blockis masked based on data stored in a mask register of the VMM block. 16.The method of claim 13 further comprising updating a correspondingindicator in a status register of the VMM block upon receiving theinterrupt request signal at the VMM block.
 17. The method of claim 13further comprising: determining that the interrupt request signalreceived at the VMM block is not masked; asserting an internal signal;combining the internal signal with an external signal generated by anexternal signal source; and transmitting the combined signal to aprocessor.
 18. The method of claim 17 wherein: the external signal is anon-maskable interrupt (NMI) signal; and the designated external signalsource is a NMI source. 19.-21. (canceled)
 22. A method comprising:identifying one or more interrupt request lines that are coupled to oneor more devices managed by a virtual machine (VM); configuring one ormore multiplex blocks to route interrupt request signals on the one ormore interrupt request lines to an interrupt controller; and generatinga request to transfer control to the VM.
 23. The method of claim 22further comprising: configuring one or more multiplex blocks to routeinterrupt request signals on interrupt request lines that are notmanaged by the VM to a virtual machine monitor (VMM) block; configuringa mask register in the VMM block to cause blocking of interrupt requestsignals routed to the VMM block.
 24. The method of claim 22 furthercomprising: restoring a state saved during a previous operation of theVM in the interrupt controller. 25.-27. (canceled)
 28. Amachine-readable medium containing instructions which, when executed bya processing system, cause the processing system to perform a method,the method comprising: identifying one or more interrupt request linesthat are coupled to one or more devices managed by a virtual machine(VM); configuring one or more multiplex blocks to route interruptrequest signals on the one or more interrupt request lines to aninterrupt controller; and generating a request to transfer control tothe VM.
 29. The machine-readable medium of claim 28 wherein the methodfurther comprises: configuring one or more multiplex blocks to routeinterrupt request signals on interrupt request lines that are notmanaged by the VM to a virtual machine monitor (VMM) block; andconfiguring a mask register in the VMM block to cause masking/unmaskingof interrupt request signals routed to the VMM block.
 30. Themachine-readable medium of claim 28 wherein the method furthercomprises: restoring a state saved during a previous operation of the VMin the interrupt controller.